Date Time: 2026-04-10 08:26:33 Location: [Insert Location]: [Insert Location] Instructor: [Insert Name]: Kevin Sullivan
The series of lectures, delivered by Kevin Sullivan, explores the future of programming at the intersection of traditional deductive software engineering and emerging inductive AI methods. The central argument is that the future lies not in replacing deductive systems with inductive ones, but in their synergistic marriage. This is primarily exemplified by the Lean proof assistant, a functional programming language that embodies the Curry-Howard correspondence—the principle that theorem proving is isomorphic to functional programming.
Initially, the discussion contrasts the high reliability required for mission-critical systems (e.g., avionics software demanding failure rates of 10⁻⁹ per hour) with the inherent unreliability of Large Language Models (LLMs), which have error rates orders of magnitude higher. While testing is insufficient to prove the absence of bugs, formal verification has historically been too costly and laborious for widespread use. The revolution now underway involves using LLMs to generate proofs that are then verified for correctness by deductive proof assistants like Lean. This drastically reduces the cost of formal verification, making provably correct software a feasible standard for high-reliability systems.
The lectures then provide an introduction to Lean, framing it as a tool for a CS1-level course that teaches functional programming and automated proof construction. The core concept of the Curry-Howard correspondence is detailed, explaining how logical constructs map directly to programming types: logical implication (P implies Q) corresponds to a function type, conjunction (P and Q) to a product type (pair/tuple), and disjunction (P or Q) to a sum type (tagged union). In Lean, propositions are treated as types, and proofs are the values that inhabit these types, with falsity represented by an empty type.
Finally, the discussion covers program verification within Lean, explaining how to ensure a compiler’s correctness by formally proving that the semantics of the source and compiled code are equivalent. The ultimate takeaway is a predicted shift in software development: as AI becomes more adept at generating implementation code and proofs, the most critical skill for developers will be the ability to write precise, high-quality logical specifications. Students are urged to become fluent in this new paradigm by learning functional programming with tools like Lean, positioning themselves to leverage AI for creating verifiably correct software.
Contrasting Reliability: Mission-critical systems like flight avionics require extremely high reliability (e.g., a failure rate of 10⁻⁹ per hour), meaning the software should never cause a catastrophic failure. In contrast, current LLMs have much higher error rates (e.g., 10⁻¹), a reliability gap of 100 million times. This makes unverified AI-generated code unsuitable for such critical applications.
Limits of Testing: Testing can only reveal the presence of bugs, not prove their absence. Exhaustive testing is computationally impossible for most systems, making it an inadequate method for ensuring the reliability needed in critical software.
Deductive vs. Inductive Reasoning:
Deductive: Traditional software operates on deductive reasoning, where program commands are deterministic logical statements. Formalisms like Hoare logic provide a sound basis for proving program correctness.
Inductive: AI and LLMs use inductive reasoning, making probabilistic predictions from vast datasets. This is inherently "unsound" and leads to phenomena like "hallucinations."
A Marriage of Both: The future of programming is not the replacement of deductive logic with inductive AI, but their integration. This synergy allows LLMs to assist in creative or laborious tasks (like generating proof outlines) while deductive systems provide rigorous verification.
Core Principle: The Curry-Howard correspondence establishes an isomorphism between theorem proving and functional programming. This allows propositions to be represented as types and proofs as values of those types. This principle serves as an "on-ramp" for programmers to enter the world of formal verification using their existing functional programming knowledge.
Mapping Logic to Types:
Implication (P → Q): Corresponds to a function type (α → β). A proof of an implication is a function that transforms a proof of P into a proof of Q.
Conjunction (P ∧ Q): Corresponds to a product type (α × β). A proof of a conjunction is a pair containing a proof of P and a proof of Q.
Disjunction (P ∨ Q): Corresponds to a sum type (tagged union). A proof of a disjunction is a value that is either a proof of P or a proof of Q. Using such a proof requires a case analysis.
Logic in Lean:
Propositions (e.g., 2 + 3 = 5) are types within the Prop universe. A proof is a value that inhabits that type.
Falsity is represented by an empty type (a type with no values). Negation (not P) is defined as a function from P to an empty type (P → False).
Lean as a Functional Language: Lean is an expressive functional programming language with features like nat types, standard operations, and a REPL-like #eval command. The #check command is used to determine an expression's type.
Lean as a Proof Assistant: Lean assists users in constructing proofs interactively; it does not find them automatically like a model checker. The user provides the high-level reasoning steps.
Tactics: Tactics are programs or macros that automate the application of basic rules of inference, simplifying the proof construction process for the user.
The Revolution: LLMs + Proof Assistants:
The historically high cost of formal proof is plummeting due to the synergy between LLMs and proof assistants.
An LLM can propose a proof, which the proof assistant (like Lean) then rigorously verifies through type checking. If the proof is incorrect, the AI agent uses the error feedback to iteratively correct it.
Program and Compiler Verification: To achieve high assurance, every component of the system must be verified, including the compiler. In Lean, one can implement the source language, target language, and the compiler itself, and then formally prove that the semantics of the compiled code are equivalent to the source. If this proof type-checks, it gives extremely high confidence that the compiler is correct.
Future of Software Development:
The primary skill for future developers will shift from writing implementation code to writing precise logical specifications.
As the cost of proof generation approaches zero, software with embedded proofs of correctness will become standard for anyone who values reliability.
This revolution is gaining traction in industry, with companies like Alphabet (DeepMind), Amazon, and Bytedance heavily investing in Lean and formal verification.
[Insert Question/Confusion]
Go to the course website kevinsullivan.github.io/lean4cs1, fork the git repository, clone it, and set it up locally with VS Code and Docker.
Work through the introductory course materials to learn the basics of Lean functional programming and its connection to logic.
Practice thinking of logical operations (implication, conjunction, disjunction) in terms of their corresponding programming data structures (functions, pairs/products, unions/sums).
Investigate the capabilities of the Lean proof assistant and its integration with AI.
Practice writing logical specifications to become fluent in this critical skill for future software development.
Compare the reliability standards for different types of critical systems (e.g., avionics, medical devices).
Research the companies mentioned (Alphabet/DeepMind, Amazon, Bytedance) and their specific projects involving Lean and formal verification.
(For students in Henry Kautz's class) Prepare presentations for the upcoming sessions (five on April 17, 2026, and more in the following week).
(For students in Henry Kautz's class) Finish up video projects.